N-way synchronization of desktop images

ABSTRACT

Methods and systems for n-way cloning and synchronization of a user desktop image are provided. Example embodiments provide a Cloning and Synchronization System (“CSS”) which binds a server stored CVD object representing the user&#39;s desktop image to one or more endpoint devices. Each endpoint device receives a clone of the CVD object that comprises one or more layers of the server CVD depending upon the suitability of the endpoint device hardware and operating system to the server stored desktop. The cloned CVDs in the endpoint devices are then kept synchronized by synchronization operations. In one embodiment, the CSS allows only one endpoint device to act as a master device and push up changes to the server CVD. These changes are then pushed down to the other devices using different synchronization methods dependent upon the layer.

CLAIM OF PRIORITY

This Application is a continuation of, and claims benefit of, U.S. Pat.No. 9,477,491, issued Oct. 25, 2016 from Application Ser. No.13/732,320, filed on Dec. 31, 2012, entitled “INDEPENDENTSYNCHRONIZATION OF VIRTUAL DESKTOP IMAGE LAYERS”, which in turn claimsbenefit of U.S. Provisional Application No. 61/581,501, filed Dec. 29,2011, entitled “MULTI-DEVICE CLONING AND SYNCHRONIZATION”, all of whichare incorporated herein by reference in their entireties.

RELATED APPLICATIONS

This Application is related to U.S. Pat. No. 9,069,579, issued Jun. 30,2015, entitled “N-WAY SYNCHRONIZATION OF DESKTOP IMAGES”; U.S. Pat. No.9,417,889, issued Aug. 16, 2016, entitled “FAST PROVISIONING OF ACENTRALIZED VIRTUAL DESKTOP USING LINKED CLONES WITH OVERLAIDCENTRALIZED VIRTUAL DESKTOP LAYERS”; U.S. Pat. No. 9,063,756, issuedJun. 23, 2015, entitled “DEVICE DEPENDENT RULES FOR SYNCHRONIZINGDESKTOP IMAGES AND MANAGING HARDWARE DEPENDENCIES”; U.S. Pat. No.8,301,874, entitled “ATOMIC SWITCHING OF IMAGES IN DESKTOP STREAMINGOVER WIDE AREA NETWORKS,” issued Oct. 30, 2012; U.S. Pat. No. 7,953,833,entitled “DESKTOP DELIVERY FOR A DISTRIBUTED ENTERPRISE,” issued May 31,2011, all of which are incorporated herein by reference in theirentireties.

TECHNICAL FIELD

The present disclosure relates to methods, techniques, and systems forprovisioning and synchronizing desktop images and, in particular, tomethods, techniques, and systems for provisioning and synchronizing adesktop image across multiple, potentially heterogeneous, devices.

BACKGROUND

The growing popularity of new computing devices, most notably tabletcomputers, has created demand for access by a tablet user to his/hercorporate computing environment using these devices from anywhere,including access to applications, content, and user profiles. There areseveral challenges associated with this requirement:

a. Tablet computers today are predominantly running non-Windowsoperating systems, whereas most corporate applications are stillWindows-based, especially client applications that execute on personalcomputers (“PCs”).

b. Tablet computers are designed to be mostly “reading” devices withlimited “write” capabilities. This means that many corporate employeesneed to be able to work with multiple devices, including traditionalWindows-based PCs to generate content, as well as with the new tabletdevices, smart phones, and the like.

c. These tablet devices present a security hazard since they aretypically not controlled by a corporate IT department, do not runcompany anti-virus software, data-leak protection software and othersoftware that provides some security measures.

One potential solution to enable a tablet computer access to a corporateenvironment is to use one of many existing programs that allow a user toconnect the tablet directly to the user's personal PC via a “remotedesktop protocol” program, which is then connected to the corporateenvironment, including access to applications and corporate data. Whilethis “chained” model may work for fixed desktops that are always turnedon and connected online to the corporate network, it does not work whenthe corporate PC is a laptop—which comprises the majority of corporatePCs. Unlike desktop computers, laptop computers are not turned-on whennot in use (they are typically in “sleep” or “hibernate” mode).Furthermore, laptops and desktops are often located away from the office(e.g., at home) and the organizational intranet, in both casesinaccessible from a remote connection.

An alternative approach is to replace the personal PC with a personalvirtual machine that is hosted in the corporate data-center and containsthe same set of applications and data as the physical PC. This typicallyrequires a system such as a Virtual Desktop Infrastructure (VDI) systemthat also knows to manage a pool of VMs and redirect users to theirpersonal VMs. Using such a centralized virtual desktop, tablet usersgain universal access to their PC. However, there are two main drawbacksto this approach.

First, by centralizing the personal PC in the data center, the user nowhas to compromise her working environment even when she can and wants towork directly with a local (physical) PC. In other words, even when theuser is present in the office and could be working directly with thelocal PC, the user is required to use the virtual desktop as if the useris remote. Working remotely typically means a poor user-experience sinceevery interaction with the central desktop involves network round-tripmessages and therefore becomes sensitive to latency and bandwidthconstraints. Furthermore, the user cannot work offline (disconnected tothe data center), an important consideration for laptop and mobiledevice users.

Second, the cost associated with supporting a centralized infrastructurethat hosts all corporate PCs in the data center is extremely high, bothin terms of compute and storage costs. For a population of existinglaptop users, where the hardware resources already exist at theendpoints (the laptops), duplication in the data center results in asignificant waste of resources.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an example block diagram of an environment for using a Cloningand Synchronization System.

FIG. 2 is an example block diagram of an environment for using a Cloningand Synchronization System.

FIG. 3 is an example block diagram of the architecture of an exampleCloning and Synchronization System according to example embodiments.

FIG. 4 is an example block diagram of how different CVD image layers canbe used to clone and synchronize portions of a desktop to endpointdevices.

FIG. 5 is an example block diagram of a computing system for practicingembodiments of a Cloning and Synchronization System.

DETAILED DESCRIPTION

Embodiments described herein provide enhanced computer- andnetwork-based methods and systems for offering a combination ofuniversal access to a centralized copy of a desktop when needed, alongwith native user experience through local execution, whenever possible.Example embodiments provide a Cloning and Synchronization System(“CSS”), which provides an effective method to clone a logical desktopimage, typically stored in a data center, across multiple devices, alongwith near continuous synchronization of user content. This allows accessto a common desktop to be generalized beyond virtual and physicalmachine sharing to any number of different machines, with potentiallyheterogeneous hardware, such as a PC, a laptop, and a mobile device. TheCSS combines universal access with the benefits of local executionthrough use of a CSS server in the data center and a CSS client on eachtarget device. The CSS server may be a special purpose computer, ageneral purpose computer suitably programmed, or a set of logic orinstructions that control one or more processors in one or more computersystems in the data center to manage the cloning and synchronization ofa user's desktop. The CSS client typically comprises a set of logic orinstructions that control receiving and managing the cloned desktop on atarget device and synchronizing updates thereafter.

The target computing device (also referred to as “endpoint” or “endpointdevice”) can be a virtual or a physical machine and can have limitedphysical storage space that may be smaller than the size of the entiredesktop image that is centrally maintained for that computing device.The cloned desktop is accordingly adjusted, for example, by downloadingonly some of the files and using stubs in place of some files with“on-demand” access by a device driver capable of recognizing how to loadthe files that have not yet been downloaded. These and other delayeddelivery mechanisms may also be used as described in related U.S. Pat.No. 8,301,874.

As used herein, “desktop image” (or just “image”) refers to data andexecutables that comprise substantially the entire content that isstored at a target computing device, including typically the operatingsystem (OS), applications, configurations and settings, as well as alluser data and files. For example, in some embodiments, a desktop imageincludes all files that are stored on one or more physical storagedevices (e.g., such as hard disks, solid state storage devices, and thelike) in a computing device. In some embodiments a desktop imageexcludes files that are temporary or transient in nature and that do notneed to be centrally managed. A desktop image may include a collectionof files that store data in compressed or non-compressed form, and thedata may be unformatted (e.g., binary data, raw disk blocks, raw datapartitions, etc.) or structured as various types of files (e.g., datafiles, DLL files, executable files, personal user files of various filetypes, various types of configuration files, etc.) and/or any other typeof data structure format.

The collection of files included in a desktop image (the logical desktopimage) is referred to as a Centralized Virtual Desktop (CVD) or CVDobject. The CVD object, as described further below, comprises aplurality of layers, some or all of which may be cloned to a targetcomputing device depending upon the hardware and operating system of thetarget device and desirability for synchronizing some or all of theinformation. For example, heterogeneous devices with different versionsof an operating system (such as a Windows XP and Windows 7) may be ableto synchronize desktop image information. In other situations they maynot be able to synchronize OS level information, but may be able tosynchronize system applications. In an example embodiment, the layersmay comprise one or more of: user data, profiles, user and systemsettings, user applications, machine identity, a base image includingone or more of an OS, infrastructure software, and core applications,and a driver library or equivalent. Some embodiments decouple the driverlibrary and other hardware dependencies from the rest of the CVD sothat, once cloned, these hardware specific aspects are not overwrittenby a synchronization activity.

Related U.S. Pat. No. 7,953,833 describes use of a CVD, as a virtualrepresentation of a desktop that can be bound at any point to exactlyone physical device. The system described therein allows anadministrator to “re-assign” the CVD from one device to another target(endpoint) device. The target computing device can be a virtual machine,in which case the re-assignment occurs from a physical to a virtualdevice and incorporates the needed transformations to adapt the CVD tothe new (virtual) hardware.

One use case addressed by the CVD mechanism described in U.S. Pat. No.7,953,833 is to provide business continuity in the face of disasterrecovery: for example, when a user's laptop is lost or damaged, anInformation Technology (IT) administrator can re-assign the CVD to acentralized VM, which in turn enables the user to access her desktopinstantly through a remote desktop protocol. Furthermore, when the usereventually receives a replacement physical laptop, the CVD can bere-assigned back from the virtual machine to the new physical machineand the user allowed to continue to work locally. Another use caseaddressed by this CVD mechanism is to restore the system from an oldersnapshot, thereby allowing the administrator to repair a device havingcorrupted software or an error to a previous system state with a lastknown working configuration.

However, the mechanism described in U.S. Pat. No. 7,953,833 is limited.A CVD can be assigned to only one (physical or virtual) device at atime. This one-to-one mapping between device and CVD may work for thedisaster recovery use case, where there is inherently only one devicethat is being used by a user at a time, but is not applicable for casesin which the user maintains more than one active device at a time. Forexample, when a user is sharing a logical desktop image with multipleendpoints, the user may perform updates to data, applications, settings,etc., from any of the devices, and changes that are made to a devicethat is not bound to the CVD object would be lost whenever the CVD isre-assigned to that device. Another drawback of the one-to-one mappingis that, in cases where a user transitions between one device andanother frequently (as may be the case with tablets or other mobiledevices and PCs), the re-assign operation, which consists oftransferring data over the network (typically a wide area network) andrebooting the target device, can take longer than the user is willing totolerate. These scenarios are exacerbated by the proliferation of mobiledevices and tablets and their use alongside PCs.

Architecture and Use of the Cloning and Synchronization System

The CSS architecture extends the notion of the general CVD mechanism toprovide a one to many, CVD to multiple target device, architecture andto keep the multiple target devices synchronized. In one embodiment, oneof the multiple target devices is designated as the “active” device or“master.” Only changes made by an active device to user content and/orsystem content when applicable may be propagated (pushed up) to theserver stored CVD. These changes are then pushed down to the other,inactive, target machines to keep them synchronized. That way, when adifferent target device becomes the new active device, e.g., the userswitches to using another one of her devices, it is already synchronizedand contains the latest updates. Applicability refers to that in somecases only some types of synchronization between devices is desired. Forexample, devices with different operating systems may not participate inOS level and/or in application level synchronization.

Generally, the user content of the target devices is kept updated on anear continuous basis, termed “live sync,” while the rest of the content(e.g., the OS, applications, system software and configuration files,and the like), when applicable, is synchronized on a “lazysynchronization” basis. That is, content that potentially requires theuser to reboot or that requires other interruption of the user may bedownloaded and/or partially integrated into the system in a staging areabut not immediately integrated into the device (e.g., registry, OS,etc.) until convenient for the user. Other embodiments of the CSS mayperform synchronization at other times and may download non-user contenton a streamed, delayed, or on-demand type of basis. CSS synchronizationoccurs without the user needing to use any type of check-in or check-outprocedure or be otherwise aware that synchronization is occurring. Thus,aside from an occasional need to reboot the system, the synchronizationprocess is relatively transparent to the user.

In addition, in some embodiments, inactive devices (the devices notdesignated the active/master device) are permitted to make changeslocally to user content (such as user files, user settings, and thelike) but are not permitted to make changes to system related contentsuch as the OS, registry settings, system software, drivers and the likeunless and until the device becomes the active device. These localchanges to user content are merged with updates from the server CVDimage pushes in a manner described below. In some embodiments, users ofdevices including inactive devices are permitted to install personal“user-installed” applications in a separate layer (e.g., see 411 in FIG.4), which are distinct from the common set of applications that comprisethe base image. These personal user apps can reside side by side withthe commonly shared base image, and are not synchronized with the restof the devices. In some embodiments, inactive devices are permitted topush changes to (only) user content in a more immediate fashion to theserver CVD, which are then propagated in near real-time to all of theother devices. This latter mechanism allows local changes to beintegrated and pushed to other devices to be seen more immediately. Sucha mechanism may be particularly helpful when a user is simultaneouslyusing two devices, such as a tablet or smartphone and a PC.

FIG. 1 is an example block diagram overview of use of a Cloning andSynchronization System. FIG. 1 illustrates an environment 100 thatshares a desktop image, represented as a CVD 101, among multipleheterogeneous endpoint devices 110, 120, 130, 140, and 150. CVD 101, thecurrent desktop image, is typically stored centrally in a data centeralong with other CVD snapshots 170 that may represent the desktop atother points in time. CVD snapshots 170 may provide the ability to backup and/or restore the desktop to different endpoint devices as needed.As shown, user 160 is currently operating laptop 120 and thus laptop 120is the “active” or master device. However, the user also has a need towork with the desktop on PC 110, on a mobile device 140 such as theuser's smartphone, and on tablet 150. The mobile device 140 and tablet150 are connected to one or more virtual machines 132 hosted by servers130 accessed using a remote protocol such as RDP (Remote DesktopProtocol). When the user 160 makes changes to the user files 121 or OSdata, registry settings, and the like 122, the files are transferred(e.g., forwarded, communicated, sent, etc.) using push operation 102 tothe server stored CVD image 101. Copies of these files 111 and 131 arethen transferred to the other endpoints using push operations 103 and104, respectively, from the CSS server (e.g., in the data center) to theCSS client residing in the PC 110 and the host 130. In this manner, thedesktop image used by the PC 110 and the VM 132 are kept current (in“sync”) with the changes to the desktop made by the user 160 on laptopdevice 120. The initial cloning of the CVD (desktop image) 101 to theendpoint devices is described with reference to FIGS. 2 and 3.

In some embodiments, as mentioned above, the CSS may allow changes touser content (such as user files and data) associated with the inactivedevices such as PC 110 and the devices serviced by VM 132 (e.g., mobiledevice 140 and tablet 150) to be pushed to the server CVD image 101,using for example, push operations 105 and 106, in near real-time evenwhen the devices are not active. Such behavior may be particularlybeneficial when the user is simultaneously using multiple devices.Because this behavior may occur only in some instantiations of the CSSand is not mandatory to implement the one-to-many synchronization, thepush operations 105 and 106 are shown using lighter weight dashed lines.

FIG. 2 is an example block diagram of some of the different types ofcloning and synchronization that may be employed by a CSS. The CSSenvironment 200 shown includes a CSS server 201 and four different typesof endpoint devices that wish to share CVD image 202 centrally stored onthe CSS server 201. For the sake of example, the CVD 202 image has beenprovisioned for a Windows OS 204 and thus includes content specific tobringing up a user desktop on a Windows based system. CVD 202 is alogical representation of the user's personal desktop environment asstored offline in the CSS server 201 data repository (for example, inone or more storage devices).

CVD 221 is an instantiated, cached copy of CVD 202 after it has beencloned to personal laptop workstation 220. Of note, since the operatingsystem for the PC is Windows based (the same as the reference CVD), thewhole CVD 221 can be cloned from image CVD 202 except for hardwaredependent aspects such as the drivers that support PC 220 and themachine ID information specific to device 220. Thereafter all layers ofthe CVD 221 may be synchronized with the server stored CVD 202.

CVD 211 is an instantiated, cached copy of a portion of the CVD 202image associated with at least one virtual machine from VM pool 210. Inparticular, when the CVD 202 is cloned, a special base image (OS for VM214), decoupled from the CVD 202, is instantiated specifically for avirtual machine so as not to interfere with system level softwarespecific to VMs. Thereafter, only the applications and user contentlayers of CVD 211 is synchronized with the CVD 202 to preserve the toolsspecific to VMs.

CVD 231 represents a partial clone of CVD 202 restricted to solely usercontent 232, because CVD 231 is associated with a device 230 that doesnot share the same kind of operating system as the reference base imagestored as part of CVD 202. Synchronization of the applications and OSfrom the CVD 202 may likely interfere with the operational capabilitiesof the device 230. Therefore, the applications of the CVD 202 cannot becloned and executed on device 230. However, using device 230, a user canstill access the Windows applications 213 of CVD 211 by connecting to aVM from VM Pool 210 that contains a clone of the CVD 202, which iscapable of running Windows OS and apps. Using a remote applicationaccess protocol (such as RDP), device 230 can connect to 210 and gainsaccess to the applications of CVD 211 (the clone of CVD 202). In thiscase, device 230 may access the full remote virtual machine, or mayaccess specific applications using “application stubs” 234 that usesimilar remoting protocols to access specific applications inapplications layer 213. The applications in applications layer 213 canalso access the cloned user files 203 of CVD 202 (cloned as user files212 of CVD 211). If device 230 only needs to access the user files 203of the CVD 202, than it can do this in one of two ways: 1. read-onlyaccess to the user's CVD via a web portal access 205, which is a frontend Web server that provides authenticated access to CVD files from anydevice that has a Web-browser. This web portal method is supported bythe CSS server 201; or 2. synchronizing the file content 203 directlywith device 230. In this case, there is no full synchronization butrather only user content synchronization between CVD 231 and CVD 202.

In some cases, a subset of the applications 204 that reside in the fullimage desktop stored in CVD 202 may be published to cloned devices suchas a VM from VM pool 210 and stored in application layer 213 for use byendpoint devices, such as mobile device 230. When selected forpublication by, for example, an administrator, only these applicationsmay be made available to specific endpoints. A method for indicatingsuch applications, such as an icon on the display screen of the endpointdevice, may be presented to the user to enable the user to select thepublished application of the subset 234. Further, in some scenarios,published applications may be provided by a different endpoint device,uploaded to the server CVD 202 and published (transparently to the VMsin VM Pool 210) for use by other devices, such as mobile device 230. Inthe case illustrated, the published applications 234 are running on a VMfrom VM pool 210. Native applications 233 are those provided, forexample, by a manufacturer or third party provider associated with thedevice 230. Note that when the desktop image 231 is synchronized, onlyuser content 232 is uploaded to CVD 202 or downloaded from CVD 202.

FIG. 3 is an example block diagram of the architecture of an exampleCloning and Synchronization System according to example embodiments. Inone embodiment, the CSS comprises one or more functionalcomponents/modules that work together to provide the cloning andsynchronization described with reference to FIGS. 1 and 2. Thesecomponents may be implemented in software or hardware or a combinationof both. In FIG. 3, one or more computer systems 302 and one or morestorage devices 304 are contained in data center 301, providing acentral location for IT administration, and are connected through anetwork 320, for example, a WAN, LAN, or other communications medium, toone or more computing devices 310 a-310 c of a user to enable the userto perform tasks using a shared desktop image. These computing devices310 a-310 c may be different types of hardware, such as the PCworkstation, laptop and mobile devices shown in FIG. 1. Computing device310 b is shown in expanded view to illustrate generally the componentsthat comprise the CSS on the client side that are present in eachendpoint computing device 310 a-310 c.

At least one of the computer systems 302 in the data center executes aCSS server 303, which is communicatively coupled to one or more storagedevices 304 that store and manage one or more CVD images 305 stored ondisks 306-308. The CSS server 303 communicates with a CSS client, e.g.,CSS client 311, located in each connected computing device 310 a-310 toprovide the cloning and synchronization capabilities. In particular, theCSS server 303 is responsible for transferring the CVD images 305 storedon the storage devices 304 to the endpoint devices 310 a-c asappropriate. The CSS server 303 is also responsible for pushing downfiles corresponding to the parts of a CVD image 305 being synchronized(as explained further below) and for receiving files pushed up by theone or more computing devices 310 a.

Each computing device, e.g., computing device 310 b, executes a CSSclient 311 (software, hardware, or a combination) which communicateswith the CSS server 303 in a computer system 302 in the data center toreceive cloned CVD images (or portions thereof), to receive pushed downfiles during synchronization, and to push up files to the CSS server 303when the computing device 310 b is the active device or at other timesas appropriate. In one example embodiment, the CSS client 311 maintainsstate data 312 corresponding to items such as version information ofvarious parts of the CVD and local manifest 313 which tracks theexistence and state of files that are present on the computing device,including those received from the CSS server 303. In some embodiments,signatures of files are maintained using hash values to identify whethercontents of files have changed. In addition, the file system 315 of eachcomputing device maintains a working area 315 a for files currentlyinstalled into the file system 315 and a staging area 315 b for files inthe process of being integrated, downloaded, or the like. The filesreferenced by the file system 315 are stored (can be read from andwritten to) in disk 317. These files comprise the layers of the CVDimage that have been downloaded and integrated into the computing device310 b.

Example embodiments described herein provide applications, tools, datastructures and other support to implement Cloning and SynchronizationSystem to be used for sharing a user's desktop image among multipleendpoints. Other embodiments of the described techniques may be used forother purposes. In the following description, numerous specific detailsare set forth, such as data formats and code sequences, etc., in orderto provide a thorough understanding of the described techniques. Theembodiments described also can be practiced without some of the specificdetails described herein, or with other specific details, such aschanges with respect to the ordering of the logic, different logic, etc.Thus, the scope of the techniques and/or functions described are notlimited by the particular order, selection, or decomposition of aspectsdescribed with reference to any particular routine, module, component,and the like. Also, although certain terms are used primarily herein,other terms could be used interchangeably to yield equivalentembodiments and examples. In addition, terms may have alternatespellings which may or may not be explicitly mentioned, and all suchvariations of terms are intended to be included.

The CSS architecture exemplified by FIG. 3 enables a variety of usecases, including troubleshooting a user's device remotely withoutneeding access to the device. Additional use cases supported by themulti-device synchronization model of the CSS include the followingscenarios:

a. Physical to virtual (P2V) synchronization between a physical desktopor laptop and a fixed, always online, virtual machine (VM) for universalaccess (e.g., from a tablet computer).

b. P2V synchronization between physical desktop/laptop and an on-demandor temporary VM. This capability is useful for emergency access to thedesktop and does not require an always online VM (which engendersassociated costs), but rather requires the administrator, data center,or the like, to start a VM on demand and load it with a disk image ofthe VM, which is typically stored offline.

c. P2V centralized troubleshooting—helpdesk engineers or otherprofessionals can clone a copy of the logical desktop image on acentralized virtual machine and troubleshoot the desktop, withoutrequiring access to the user's remote physical machine. Once repaired,the changes can be synchronized with the physical copy on the user'sremote physical machine.

d. Physical to Physical (P2P) synchronization between multiple physicalmachines, such as a laptop and a desktop. This synchronization couldinvolve more than two machines, and encompass “N” clones.

e. P2V synchronization between a user's work desktop and a user's homeVM. This allows a user to clone their work desktop at home using avirtual machine that is hosted on the user's personal machine and allowsthe user to run the personal and work machines at the same time.

f. User-files-only synchronization of selected directories. In thiscase, only the user content layer of the CVD is synchronized. The restof the CVD layers are not synchronized. This mechanism can also be usedin the cases in which the devices do not share the same operating system(e.g., a Mac OS device and a Windows device).

g. Sharing of user files across multiple users. The user can definepermissions for other users to access the files from a shared directory,so that other users can access the shared files. This is similar toshares on file servers, with the additional benefit of keeping historyof file versions and protecting the shared data, snapshots, automaticsynchronization to a physical device for offline work, etc.

Cloning and Synchronization Operations

The CSS architecture accomplishes extending the CVD concept to bindmultiple, potentially heterogeneous, devices using two new operations:Clone and Synchronize.

Clone (CVD, New Device)

The Clone operation takes a designated generic CVD object and clones itto a designated new device. Each CVD is bound to 1 or more endpointdevices. At the end of the Clone operation, the CVD adds (e.g.,associates, identifies, designates, etc.) a new device into the group ofbound devices managed by the designated CVD.

The Clone operation can be either end user-initiated oradministrator-initiated. In the former case, the end user operates in aself-service operation. She introduces a new device, installs thecloning and synchronization client on it (the CSS client), provides hercredentials, and then initiates a Clone operation on the CVD thatrepresents her desktop. In the latter case, an administrator (such as anIT designee) invokes the operation on behalf of the end user.

Each device can belong to at most one CVD group, and a CVD groupconsists of N devices. Note, however, that the CVD is device-agnosticand decoupled from specific hardware. Device specific aspects aremaintained in a device instance object.

In this context, the term “clone” refers to an image that isfunctionally identical but may be slightly different than the original.A clone comprises the same set of applications (both user-installed andcentrally managed applications), data, and OS, but may have differentinstalled drivers based on the underlying hardware of the designateddevice. A clone, as a distinct machine instance, will have a distinctidentity such as a different machine identifier and network address, adifferent OS license number, etc.

As mentioned above, the CVD comprises multiple layers (components). Eachlayer is cloned in a specific way. In one example embodiment, the CVDcomprises the following layers:

-   -   User files    -   User settings and profile information    -   Machine Identity (ID)    -   Application software, including user-installed applications    -   Operating system, including infrastructure and system level        software (and potentially core applications)    -   Hardware-dependent software including device drivers and        associated software.

Decoupling the CVD image into these layers is important for the successof the various cloning operations, since both the cloning and thesynchronization logic are specific to the layer being cloned.

The general concept of cloning is operating system independent.Furthermore, a CVD can be shared by multiple devices with differentoperating systems, except that, in this case, synchronization is limitedto user files and user settings. In order to accommodate differentoperating systems sharing the same CVD, user files are mapped properlyin the directory trees and user settings are selectively converted asneeded. For example, Web Browser favorites on a Microsoft Windows deviceare synchronized with their proper location on an Apple Computer Macdevice.

USER FILES—User files are “cloned” by merging the user files of the CVDwith the user files that exist on the designated target device. Ineffect, the Clone operation results in creating a (local) CVD thatcontains the union of all files from the server stored CVD and the newdevice. In case that there are conflicts between the CVD and thedesignated device, i.e., there are files with the same name and locationbut different content, a second copy of the conflicting file isgenerated (with a “copy” suffix) and kept side by side, and anotification is presented to the user, which in turn may result inresolving the conflict by deleting one of the copies or keep bothcopies.

The mechanism for performing this merge is described in more detail withrespect to synchronization of user content.

USER SETTINGS—By default, the CVD settings overwrite the settings on thetarget device and replace them. However, it is possible to define“partial” cloning that does not include user settings in the scope ofthe clone.

MACHINE ID—Machine ID settings of the CVD (which include machine name,IP address, OS license, etc.) are not mapped to the target device, i.e.,the device preserves its own Machine ID. This is important to avoidnetwork collisions that could arise from having two machines with thesame name. However, some of these settings may be useful in a restoreoperation.

APPLICATIONS AND SYSTEM—By default, these layers of the CVD overwritethe target device. One process for performing in-place replacement of anOS and application sets is described in a U.S. Pat. No. 8,301,874. Inoverview, the new information is downloaded to the target device into astaging area. Special “pivot logic” is provided by the client softwarewhich is executed as the only process running during a first boot of thedevice. This pivot logic then performs an ‘atomic switch’ of the OS bymoving files from the staging area into the working file system, anddeleting files as necessary. When the initial pivot operations arecomplete, the pivot logic then performs a second boot of the device tofinish moving or integrating components.

Note that at the end of the cloning process, the new set of system andapplication software is identical across all CVD clones, except forhardware-specific software.

HANDLING HARDWARE DEPENDENCIES—In order to cope with two devices thathave different hardware, the CSS supports a driver library, which isdecoupled from the rest of the image and contains a folder per hardwaretype with the relevant hardware-specific drivers. Upon performing theClone operation, the CSS server automatically detects the type of thetarget hardware based on matching rules stored, for example, in the CSSserver, and sends only the relevant driver folder along with the rest ofthe image. Automatic detection of the hardware type of the targetendpoint enables the automation of the cloning and synchronizationprocesses, so that they can be performed in a self-service manner by theend-users.

A driver library having folders of driver “packages” may be implementedfor different operating systems using tools available for each operatingsystem or a proprietary tool that arranges driver files into packagesthat can be installed. For example, for a Windows OS, a publiclyavailable tool such as the Microsoft Deployment Toolkit allows adeveloper to put together a complete installation package for eachdriver. Some drivers use .inf files to install; other drivers requiredifferent methods for installation into the OS.

Alternatively, the CSS server may incorporate all driver software in a“fat” driver image (decoupled or not from the rest of the base image)and transfer the entire driver image portion during the cloning process.The CSS client would then need to recognize what drivers are neededand/or applicable to the new device and cause their installation intothe cloned OS.

In another example embodiment, instead of the CSS recognizing whatdrivers are needed, the CSS triggers PnP and sets up everything for theOS to figure out which driver to use. If the proper driver is alreadyinstalled in the target image, the CSS may not re-install the driver toavoid unnecessary installation.

FIG. 4 is an example block diagram of how different CVD image layers canbe used to clone and synchronize portions of a desktop to endpointdevices. Depending upon the circumstances, a full image may be cloned asdetailed above (with the exception of handling hardware dependencies).This situation is illustrated in the full clone/synchronization scenario401. Here, a full image containing user content (user data, profiles,user installed applications) 411, IT supplied applications 412, and abase image 413 (OS, infrastructure software, etc.) is cloned onto a newdevice. (A restore operation to a target device is performed similar tothe clone.) The driver library 416 containing the drivers needed for thenew device is shown decoupled from the rest of the full image 410 since,once installed, it is not synchronized.

In some cases, it may be desired to decouple not just the hardware layerbut also the OS layer from the rest of the system, and only clone theapplication layer that is above the base OS layer. For instance, theremay be some low-level software that is only applicable to the device butis not identifiable as hardware specific or driver-based, and henceshould reside only with the new/target device. An example is “virtualmachine tools,” a common set of applications needed to operate well withvirtual machines—and should not be removed when an image is cloned froma physical device onto a virtual target device, and similarly should notbe applied when cloning from virtual to physical device.

For these cases the CSS provides partial clone/restore illustrated as“rebase” scenario 402. Here, the user content (user data, profiles, userinstalled applications) 420 and IT supplied applications 421 are cloned(or restored) onto a new/target device. Specifically, the CSS allows anadministrator to define a “base image,” 422, which includes a leanoperating system image that matches the new device and is decoupled fromthe rest of the image. In addition to OS image, the base image 422 maycontain low-level system software that should not be removed (forexample, when restored) or cloned. Using this method, a new/targetdevice is initialized with a base-layer that is applied to it, before itcan be used for multi-device synchronization purposes. Once the baseimage 422 is applied, the CSS cloning logic only clones the layers abovethe base layer (e.g., user content 420 and applications 421), which arethen merged with the target base layer (instead of overwriting thesystem layer, as done in full system cloning). An example of this typeof cloning is also illustrated with respect to the CVD 211 for the VMpool in FIG. 2.

Base images, including lean OS base images may be formed for use withthe CSS by setting up a reference machine where the OS for the targethardware is installed (or an otherwise clean image can be found) with asfew or as many components as desired, installing the CSS client, andthen capturing and storing the resultant base image. Base images may beupdated in a similar fashion.

Merging of the layers above the lean OS base layer (in the case of aWindows OS based CVD) can be performed by smart merging the file system,the registry, and several in-file/database objects specific to WindowsIn particular, smart merging of the (non user installed) applicationslayer may require updating, deleting, downgrading of DLLs andapplications, sharing of existing resources, updating the Windowsregistry, etc. Merging drivers are handled similarly. Some changes arefirst downloaded or integrated into a staging area, such as staging area315 b in FIG. 3, especially if a reboot is required and pivot logic isused to replace portions of the local desktop image.

In some embodiments, a snapshot image, for example, using Windows VS Sutility, is used to assist in the merging process.

When merging the application layer AL1 that was updated by a device D1with a base layer BI1, onto another device, D2 that has its own baselayer BI2, the following logic is applied:

-   -   The CSS client in D2 downloads a manifest of all the files in D1        and the system registry hives of D1 from the CSS server (the        manifest and registry hives contain both BI1 and AL1) in BI2 are        not added to the target device.    -   The downloaded file manifest and registry hives of D2 are        modified to create a “merged image”, as follows:        -   Entries which exist in BI1 and don't exist in BI2 are            removed.        -   Entries which exist in BI2 are added on top of existing            entries, except for specific entries which can be defined by            policy.    -   The local file system of D2 is scanned using a VS S snapshot        created on D2, creating a local manifest of the files in D2.    -   The CSS client in D2 calculates the delta of the merged file        manifest and the local manifest, creating the “delta manifest.”    -   The CSS client in D2 downloads files which aren't available in        D2 and are in the delta manifest into the staging area, which is        a dedicated protected directory. The merged registry hives are        also put into the staging area.    -   The CSS client also performs specific merge operations before        booting D2. These operations are implemented by “shims” and are        responsible for merging Windows-specific databases and handling        application conflicts.    -   The CSS client then instructs the machine to boot and runs a        boot-time CSS application (a “pivot” operation) to move files        and merged registry hives from the staging area into place,        arranging the local file system of D2 to contain the calculated        merged image which has AL1 and BI2.    -   After boot, the CSS client may complete merge operations by        running post-boot “shims”, merging any additional Windows        databases in an online manner.

As mentioned above, in some cases, special additional logic can beemployed through the use of “shims.” A shim is a code handler containinglogic/instructions that are executed before and after defined events inthe running system. Shims are associated with different hooks into thesystem and executed upon the occurrence of certain CSS events, such asupon startup, pre-upload, pre-pivot boot, etc. Active shims areconfigured via policy and can be dynamically loaded into the runningsystem. They can be used to help merge updates to abase image, specialhandling for loading drivers and the like, and migration to differentoperating system versions, etc. Shims also can handle merging twodifferent operating systems versions, which may involve more than just asimple merge of the file system and the registry.

For example, in one example embodiment, when using Windows, a softwareshim is executed to add and remove application programs and update theregistry properly. More specifically, Windows keeps a list of installedapplications in the registry. If the synchronization operation currentlybeing performed is to replace an existing application with a newerversion, then special handling is required because merging a newregistry entry by simply adding a new key will result in multipleversions of the same program instead of replacing one version of theapplication with an updated version. To resolve this problem, a CSS shimis hooked into the “pre-boot” event so that the CSS can, in the stagingarea, perform a naïve merge and then clean up the two applicationversions before the device reboot takes place. If there is a conflict,the original base image contents will prevail.

As other examples, a shim can be used to update applicationlicense-related registry keys or provide special CSS registry values inthe Windows registry, merge OEM supplied drivers by pre-loading theminto a special folder controlled by the CSS, download the entire CSSdriver store when desired (without upsetting the already installeddrivers in the local base image), install/merge network components intothe registry using Window's APIs at the relevant time in the bootprocess, and the like.

The following is a list of major merge mechanisms used by a CSS clientto properly merge two Windows instances and the included applications:

-   -   A shim for merging the Windows driver store.    -   A shim for merging Windows network components (for firewalls,        VPNs, . . . ).    -   A shim for merging and de-duplicating the add/remove program        database.    -   A shim for merging the WMI repository.    -   A shim for handling application-specific licenses (e.g. Office        2010).    -   A shim for merging the Windows side-by-side database.    -   A shim for merging Microsoft's help database.    -   Non-naïve registry merge of selected registry values.    -   Logic for extracting hardware-specific identifiers from a        Windows machine (mainly policy-based).    -   Logic for filtering temporary and log data from a Windows        machine (mainly policy-based).    -   Logic for selecting the highest version of PE files (e.g. DLLs)        when they conflict.    -   Logic for preserving PE files which are needed by user-installed        applications.    -   Logic for avoiding the overwrite of user settings and data when        merging Windows machines.    -   A reporting tool for detecting and avoiding application        conflicts both at the application level and at the module level        (e.g. DLLs).

In some cases, for example where the operating system and applicationsof the new/target device are completely different than the lean OS baseimages created for rebasing, the CSS may provide no clone but onlysynchronization of user content as described with respect to CVD 231 inFIG. 2. For these cases, the CSS provides the user contentsynchronization scenario 403, which synchronizes only user content 430.There is no need for a clone per se, because the first synchronizationof the user content will merge user content stored in the server CVDwith any user content already present on the device. Alternatively, aclone of the user content layers could be performed as specified abovewhere the user files of the CVD are merged with the user files thatexist on the designated target device.

In some cases, it is possible to leverage the CVD layering architecturein order to quickly provision a new VM from a template base imageprovided by the CSS. The template base image can be pushed down to andmaintained by the VM infrastructure as a “linked-clone,” which enablesthe virtualization infrastructure to spin an image to a new VM veryquickly, with minimal use of storage resources. That is only one copy ofthe base image is maintained for a group of VMs. The CSS can thenoverlay the base image that is cloned using the linked-clonecapabilities with the upper layers of the CVD, which are cloned usingthe CSS mechanism, including applications and potentially user content.

Synchronize

Once a device is cloned, the CSS is thereafter responsible formaintaining the synchronization of all N clones using one or moresynchronize operations such as “Sync Up” or “Sync Down.” In variousembodiments, the system supports continuous transparent fullmachine/full profile bi-directional synchronization. Here,bi-directional refers to the notion that updates to the server CVD canbe caused by pushed updates of active device or by updates to the serverCVD from another device or the CSS server.

For the purposes of an example embodiment, the following facts areassumed:

-   -   The user typically works with one device at a time, although may        occasionally use multiple devices in parallel (e.g., desktop and        a smartphone).    -   Each user has a handful of devices.    -   The transition between active devices is expected to occur a few        times a day at most.    -   It is not possible to require end users to notify the system        when they are “done” with a device.    -   The synchronization method cannot assume that all devices        sharing a CVD are always connected. For example, a laptop may be        taken offline before completing its synchronization. Here        connected refers to a connection to the CSS server—not whether        it is “online,” for example communicating with the Internet.    -   When a user switches to a new device from the same clone-set        (devices bound to the same CVD), the user should be able to        start working with it quickly with minimum delay.

Taking these considerations into account, an example CSS synchronizationmethod works as follows:

At any point in time, one device from the CVD device group is denoted asthe “active” or “master” device. A device becomes active by the CSSassigning the active role to the device, once the CSS detects that auser is actively working on that device. The CSS can detect that theuser is actively working by detecting (e.g., identifying, determining,monitoring, etc.) interaction including mouse movement and keyboardactivity. Other methods, such as detecting a login and using heuristicsregarding the device hardware type may also be employed. The CSS clientcan monitor such activity on a frequent or periodic basis, and evencontinuously. In some embodiments, a certain threshold of time needs topass before switching to a new device to avoid thrashing back and forththe active role between devices. In one embodiment, a device having theactive role is the only device that is allowed to upload changes (fromany layer) to the server CVD. According to this embodiment, the activedevice, through the CSS client, performs periodic uploads of localchanges made in the device to the server CVD.

An inactive device (a device that has not been assigned the active role)is not performing updates to the server copy of the CVD, but if it isonline, it receives updates made by the active device through its CSSclient. This proactive push of updates reduces the time it takes for aninactive device to become active and fully updated. The CSS blocks aninactive device from performing “system-level” (base image, applicationlayer, etc.) changes locally, such as installing new applications,updating the operating system, etc. This restriction is acceptable sincethe example embodiment assumed that only one device is being activelyused by the user. However, an inactive device may still update userfiles and data locally on the device, in which case the CSS has to beable to cope with multiple devices performing changes to user files,although they do not perform simultaneous updates to the server copyaccording to this embodiment. Rather, the local updates are merged withthe server CVD when the inactive device later becomes active. Updatespushed down from the server CVD are merged, as described below, topreserve both local changes and changes made by other devices.

In another embodiment, inactive devices can perform periodic updates oflocal changes made only to the user content at the same time as theactive device performs updates to content and other devices performupdates to user content. This latter arrangement is useful inembodiments that assume more than one device can be used simultaneously.However, the CSS server needs to synchronize the updates to the serverCVD by performing them, for example, in a sequentially preserved order,by using a locking mechanism, or some other feature. This complexity isnot necessary when only the active device (or CSS server) can pushupdates to the server CVD.

In an example embodiment, the following synchronization logic is appliedby the CSS:

In a steady state, where a device D2 is the active device, the CSSclient on D2 periodically checks whether D2 has conducted an update anduploads the delta (the files that have changed) to the server copy ofthe CVD by communicating with the CSS server. Note that the CSS clientmay employ a different upload frequency for user files versus systemfiles (e.g., user files may be subject to a “sync now” policy, whereasapplication/system files may be updated on a periodic base). Also notethat for application/system files, a point in time snapshot is typicallytaken to ensure consistency, whereas for user files there is no need forsnapshot (the user files are merged as described below)). If anotherdevice in the device group bound to the CVD, for example D1, is on-line,then D1 would periodically check if the content on the server CVD isnewer than the version it has, and, if so, would trigger a sync downoperation if so. As described below, the sync down operation may workdifferently for different layers.

As an example, assume that the user is approaching device D1 and wantsto work with it. Previously the user was working on device D2, which wastherefore marked as the active device. At this moment the CSS clientrunning on D1 detects user interaction on D1 and wants to switch theactive role to D1. The following steps are performed by the CSS:

-   -   1. Upload a snapshot of D1. This step ensures that D1 can be        restored to its state prior to the synchronization operation in        case the synchronization causes an undesirable outcome.    -   2. Sync up of D2: If the previously active device, D2, is        connected, then D2 synchronizes all pending changes with the        server copy of the CVD (e.g., the CSS client on D2 performs a        sync up). Note that in many cases the D2 device CVD is already        synchronized up to the server CVD due to the periodic updates        that an active device performs against the CVD. Also, note that        the CSS uses data de-duplication methods to expedite the check        for and transfer of updates, and uses system level indicators to        identify if new applications have been installed. Finally, note        that the upload by D2 creates a new snapshot of the CVD, hence        not colliding with the upload made by D1, which is used for        recovery purposes.    -   3. Sync down of D1: D1 downloads the delta updates from the        server CVD. The delta updates refer to the files that have        changed.

While performing a sync up, the CSS can employ techniques to optimizethe transfer of data over the network. For example, the followingtechniques can be used:

Sync up—

-   -   1. Endpoint device (CSS client running thereon) captures system        state and identifies potential modifications and places them        into Delta1,    -   2. Endpoint device (CSS client running thereon) calculates the        signatures for the potential modifications, compares them to        current CVD signatures and identifies changed files and places        them into Delta2.    -   3. For each unique file F in Delta2:        -   a. Check if file F was already synchronized by this or other            endpoints        -   b1. If yes—skip sync up, create logical reference on CSS            server        -   b2. If no—for each block B of file F:            -   Check if block B was already synchronized by this or                other endpoints (e.g., as a part of other files).            -   If yes—skip sync up for specific block, copy data                locally on CSS server.            -   If no—transfer block data    -   4. Endpoint device (CSS client running thereon) completes the        sync up and stores the changed files as new version of CVD.

Sync down—

-   -   1. Endpoint device (CSS client running thereon) captures system        state and identifies potential modifications and places them        into Delta1.    -   2. Endpoint device (CSS client running thereon) calculates the        signatures for the potential modifications, compares them to        current CVD signatures and identifies changed files and places        them into Delta2.    -   3. Endpoint device (CSS client running thereon) requests from        the CSS server the list of concurrent modifications that were        performed on CVD since last sync point.    -   4. Endpoint device (CSS client running thereon) calculates which        files and versions “win” according to conflict resolution table        described in Table 1 and places them into Delta3.    -   5. For each unique file F in Delta3:        -   a. Check if file F was already synchronized by this endpoint        -   b1. If yes—skip sync down, copy data locally        -   b2. If no—for each block B of file F:            -   Check if block B was already synchronized by this                endpoint (e.g. as a part of other files)            -   If yes—skip sync down for specific block, copy data                locally            -   If no—transfer block data.    -   6. Endpoint device (CSS client running thereon) completes the        sync down and reboots if required.

Note that the sync up and sync down operations may contain updates toany of the CVD layers or elements, including user files, user settings,and system & applications. However, while the download is performed forall layers, the actual operations of synchronizing the changes with therunning system are not performed on every sync operation, as the systemdistinguishes between user files changes and system/application levelchanges. System/application level changes may be performed on a delayedbasis; while user content level changes may be integrated in nearreal-time.

In particular, the CSS performs the following synchronizations for thevarious types of files:

-   -   Live sync of user files—The CSS performs a “live sync” of user        files. That is, the files are merged following the same method        as for the clone operation. The merger of user files is        described with reference to Table 1.    -   Lazy sync of user settings—This synchronization operation        requires a “user log-off/log-on” sequence in order to apply the        changes on the endpoint device. Hence, the synchronization        operation does not wait for the user settings to take place, in        order to reduce the wait time and disruption to the end user. At        a later point, if user settings have been changed, the user may        be asked to optionally log off and log on in order to apply the        new user settings, such as through a user interface control such        as a dialog box, balloon, pop-up window, etc. As with the case        of cloning user-settings, the synchronization of user settings        involves overwriting the settings of inactive devices with the        settings of the new active device.    -   Lazy sync of system and application changes—This synchronization        operation requires a restart of the device. As such, this        operation is also deferred. The user can continue to work and at        some point is prompted to restart the system in order to apply        the system changes, if such changes occurred. Note that upon        restart, the device contains the updated copy of the image,        which might be different than the previous image. In particular,        while the user content sync merges changes, system and        application sync overwrite the existing local copy as described        with respect to the clone operation. For example, in the case of        a full restore, all layers except the driver layer are        overwritten, and in the case of application level restore (a        rebase operation), the driver library and the base-image (OS)        layer are preserved, while all applications are overwritten.

In order to eliminate unnecessary synchronization at the system level ifno changes to system provided applications (and the operating system, inthe case of full restore) have occurred, the CSS checks to see if theapplication lists on the source (server CVD) and target devices areidentical, in which case it does not perform system levelsynchronization at all. This heuristic prevents the CSS from conductingan unnecessary synchronization for each change in the system files.

-   -   No sync of hardware dependent elements, or of machine        identifiers    -   Previous active device not synced up—Techniques are provided to        address the case where the previous Active device (D2 in this        example) went offline before performing its latest sync up        operation. In this case, there is a risk that changes made to        the system might be lost if incompatible with changes made since        to the system by D1. However, since the first step in the        protocol involves uploading a snapshot of D1 (the previously        active device), the user can revert back the changes that were        made to the system by D1, if so desired.

Live synchronization of user files for both cloning and synchronizationoperations is performed by merging the local files relating to usercontent with changed user files noted for the server CVD. In oneembodiment, the changed user files are determined by the CSS bycomputing the difference (the “delta”) between the area of the serverCVD image denoting user content and the area of the local CVD imagedenoting user content. The area of a CVD image denoting user content isreferred to as the “U area” and is shown as U area 414 in FIG. 4. (The Marea—or machine area—is the entire CVD image minus the U area, which isshown as M area 415 in FIG. 4.) A “manifest”—or list of files—ismaintained for the server CVD and for each local CVD. In addition, alast uploaded manifest is kept by the CSS client. For livesynchronization, the delta for consideration is the difference betweenthe server CVD manifest and the local manifest with respect to the UArea.

The CSS client on each device tracks the current version of the local Marea and the current version of the local U area in, for example, statedata 312 in FIG. 3. The CSS server maintains a single version for theentire CVD image. However, in some embodiments, the CSS server maintainsseparate version numbers for user content versus the rest of the image.On inactive devices, a live merge operation is invoked when the local Uversion is lower (older) than the CSS server's CVD version. On activedevices, a live merge operation is invoked when the only differencebetween the list of files for the server CVD and the local CVD involvesfiles in the U area (e.g., no changes have been made to the M area).

According to one implementation, after the U area delta has beendetermined, the files designated by the U area delta are downloaded bythe CSS client to a staging area of the local device (e.g., staging area315 b of FIG. 3). The files are typically download in a prioritizedorder (e.g., according to a streaming priorities mechanism such as thatdescribed in U.S. Pat. No. 8,301,874 or other priorities mechanism). Thesignature of each of these files (from the CSS server's CVD manifest) isthen compared to the signature of the corresponding file (if one exists)in the local manifest and to the signature of the corresponding file (ifone exists) in the last manifest that was uploaded by this device todetermine the disposition of the file (per file action) according toTable 1. The signature of a file may be computed using any knownmechanism, for example, to compute a unique hash value representative ofthe content. In overview, the dispositions addressed by Table 1 insurethat 2 files that are different co-exist side-by-side in the resultingmerged U area. The determination of each file is typically performedimmediately after downloading the file, however, such can be done atdifferent times as well. Once the files in the staging area are merged,the CSS client updates the version of the local U area to be equal tothe server CVD version.

TABLE 1 Last Local Upload Server Case Description CSS Action 0 0 1 Fileadded by another Move down- device, doesn't exist loaded file locallyinto place 0 1 0 File deleted by another No action device, doesn't existlocally 0 1 2 Locally deleted Move down- file was modified loaded fileby another device into place 1 0 1 Recreated file is same No action(don't download file) 1 0 2 Recreated file is different Move down-loaded file into place with unique name (e.g. “Conflicted . . .”) 1 1 0Another device deletes Delete local file file 1 1 2 Another devicemodifies Move down- file loaded file into place (overwrite local file) 12 0 Locally modified file was No action (possibly deleted by anotherdevice notify) 1 2 1 Locally modified file was No action modified in thesame way by another device 1 2 3 Locally modified file Move down- wasmodified differently loaded file by another device into place withunique name (e.g., “Conflicted . . .”)

In Table 1, the “Local” column refers to the signature of the fileidentified by the local manifest. The “Last Uploaded” column refers tothe signature of the file identified by the last manifest that wasuploaded by this device to the CSS server. The “Server” column refers tothe signature of the file identified by the CSS server's CVD manifest. A“0” entry means that the file does not exist. A “1,” “2,” or “3,” entrydesignates different signatures in the abstract.

In some embodiments, native snapshots supported by the native operatingsystem of a device may be used to aid in the determination of what todownload (the delta). For example, the VS S tool may be used for thispurpose in Windows. Also, in some embodiments, instead of preloading thestaging area with all of the user files in the delta and then processingthem one by one, the signature of each file may be checked fordisposition and then a separate download request generated for eachfile. In other embodiments, the “last modified” timestamp of a file isused instead of a file signature to determine whether it has beenchanged. Also, in some embodiments, other activities such as base imageupdates may be temporarily disallowed while performing the merge. Also,if two (or more) devices are making changes to a same file, it maybecome important to set a limit to the number of times the file isduplicated and saved with a new name.

In some embodiments, near continuous updates from multiple (inactive)devices to the server CVD are supported for user data. That is, inactivedevices as well as active devices are permitted to update user contentof the server CVD without needing to be designated the active design.This design is demonstrated by operations 105 and 106 shown in FIG. 1.In this scenario, when the CSS detects that two devices are trying toupload at the same time, it might choose to reject one of them. Therejected device will eventually detect that the server CVD version ishigher than the local version and will perform a live sync action (and Uarea merge) of the user content.

The synchronization of system and application changes to inactivedevices, typically with use of a lazy sync operation, occurs when thecurrent version of the M area stored for the local CVD, for example, instate data area 312, is lower (older) than the server CVD version. Inaddition, in some embodiments the CSS client detects that significantchanges have occurred, before engaging in this synchronization process.For example, the CSS client may determine that the list of applicationsin the server CVD is different that the local CVD application list andthe pending application list (those changes stored in a staged area butnot yet integrated). As other examples, the CSS client may determinethat a significant amount of registry user settings have changed, userprofiles were added or removed, an IT administrator is requesting thissync operation, this is the first time the M area on the local CVD isbeing updated, etc.

This synchronization operation (sync down of the M area) is performed byconducting a system-only restore of the M area to the staging area, suchas staging area 315 b of FIG. 3. This restore operation will take intoaccount and integrate any files previously loaded into the staging areabut not yet integrated into the system. Once the download is completed,the CSS client will notify the user that an update is available. Forexample, the CSS client may cause a user interface control such as adialog box, pop-up window, text message, or the like to be presented tothe user. The user is then free to either restart (reboot) the systemand apply the changes or ignore them. The CSS client then returns to itsmain event loop and examines the CVD info to decide on a next action. Insome embodiments, a time period for rebooting is employed to enforce alatest update when a large amount of time has passed. Also, as analternative to using a system-only restore of the M area, the CSS maychoose to apply the base image layer with “cleanup” of the M area, suchas, for example, using the shims discussed above.

When two or more devices are being used simultaneously by the user, theCSS may decide that a simple deployment of lightweight user contentsynchronization using the live merge of the U area described above makesmore sense than keeping the rest of the CVD layers synchronized. In sucha case, the CSS need not differentiate between active and inactivedevices.

Also, in the process of cloning and/or synchronizing CVDs, the CSS maydetect that a device has insufficient disk space to store the contentsof a copy of the server CVD. In such a case, the CSS may support acache-mode capability which enables an endpoint to operate with only afraction of the image resident (up to the size of the disk of the targetdevice) and “leave behind” some of the content. If the user needs toaccess content that is not resident, the CSS fetches that contenton-demand from the server copy of the CVD, and evicts from the endpointdevice files that have not been accessed recently. The eviction mayinvolve deletion of the file from the file system and replacing it withan “offline” file, which keeps a stub for the file in the file systembut does not actually store the file contents. When a user makes arequest to access a file that is offline, the system intercepts therequest and fetches the file on-demand from the server.

In order to expedite cloning and synchronization operations, the CSSsupports the ability to stream some of the content on demand, ratherthan having to synchronize all content in advance before completing thesynchronization. This is particularly important for cloning andsynchronization of user content, since the amount of synchronizedcontent can be very large although large portions of the content arerarely accessed by the users. Hence, by keeping a profile of the morecommonly used files as part of a CVD profile, the CSS can determine asmall “working set” of commonly used files, and stream only them for thenew (or synchronized) device. This method will promote a fastercompletion of the cloning and synchronization operations. Once theworking set is synchronized, the rest of the files can be delivered tothe new/updated device on demand or in the background.

Computing Devices for Implementing a CSS

The techniques described herein for cloning and synchronization can beimplemented by one or more special-purpose computing devices. Thespecial-purpose computing devices may be hard-wired to perform thetechniques, or may include digital electronic devices such as one ormore application-specific integrated circuits (ASICs) or fieldprogrammable gate arrays (FPGAs) that are persistently programmed toperform the techniques, or may include one or more general purposehardware processors programmed to perform the techniques pursuant toprogram instructions in firmware, memory, other storage, or acombination. Such special-purpose computing devices may also combinecustom hard-wired logic, ASICs, or FPGAs with custom programming toaccomplish the techniques. The special-purpose computing devices may bedesktop computer systems, portable computer systems, handheld devices,networking devices or any other device that incorporates hard-wiredand/or program logic to implement the techniques.

FIG. 5 is an example block diagram of a computing system for practicingembodiments of a Cloning and Synchronization System. Computing system500 may comprise one or more server and/or client computing systems andmay span distributed locations. In addition, each block shown mayrepresent one or more such blocks as appropriate to a specificembodiment or may be combined with other blocks. Moreover, the variousblocks of the CSS may physically reside on one or more machines, whichuse standard (e.g., TCP/IP) or proprietary interprocess communicationmechanisms to communicate with each other.

Computing system (or computer system) 500 includes a bus 502 or othercommunication mechanism for communicating information, and a hardwareprocessor 504 coupled with bus 502 for processing information. Hardwareprocessor 504 may be, for example, a general purpose microprocessor.

Computer system 500 also includes a main memory 506, such as a randomaccess memory (RAM) or other dynamic storage device, coupled to bus 502for storing information and instructions to be executed by processor504. Main memory 506 also may be used for storing temporary variables orother intermediate information during execution of instructions to beexecuted by processor 504. Such instructions, when stored innon-transitory storage media accessible to processor 504, rendercomputer system 500 into a special-purpose machine that is customized toperform the operations specified in the instructions.

Computer system 500 further includes a read only memory (ROM) 508 orother static storage device coupled to bus 502 for storing staticinformation and instructions for processor 504. A storage device 510,such as a magnetic disk or optical disk, is provided and coupled to bus502 for storing information and instructions.

Computer system 500 may be coupled via bus 502 to a display 512, such asa cathode ray tube (CRT), for displaying information to a computer user.An input device 514, including alphanumeric and other keys, is coupledto bus 502 for communicating information and command selections toprocessor 504. Another type of user input device is cursor control 516,such as a mouse, a trackball, or cursor direction keys for communicatingdirection information and command selections to processor 504 and forcontrolling cursor movement on display 512. This input device typicallyhas two degrees of freedom in two axes, a first axis (e.g., x) and asecond axis (e.g., y), that allows the device to specify positions in aplane.

Computer system 500 may implement the techniques described herein usingcustomized hard-wired logic, one or more ASICs or FPGAs, firmware and/orprogram logic which in combination with the computer system causes orprograms computer system 500 to be a special-purpose machine. Accordingto one embodiment, the techniques herein are performed by computersystem 500 in response to processor 504 executing one or more sequencesof one or more instructions contained in main memory 506. Suchinstructions may be read into main memory 506 from another storagemedium, such as storage device 510 or other computer readable media 509.Execution of the sequences of instructions contained in main memory 506causes processor 504 to perform the process steps described herein. Inalternative embodiments, hard-wired circuitry may be used in place of orin combination with software instructions.

The term “storage media” as used herein refers to any non-transitorymedia that store data and/or instructions that cause a machine tooperation in a specific fashion. Such storage media may comprisenon-volatile media and/or volatile media. Non-volatile media includes,for example, optical or magnetic disks, such as storage device 510.Volatile media includes dynamic memory, such as main memory 506. Commonforms of storage media include, for example, a floppy disk, a flexibledisk, hard disk, solid state drive, magnetic tape, or any other magneticdata storage medium, a CD-ROM, any other optical data storage medium,any physical medium with patterns of holes, a RAM, a PROM, and EPROM, aFLASH-EPROM, NVRAM, any other memory chip or cartridge.

Storage media is distinct from but may be used in conjunction withtransmission media. Transmission media participates in transferringinformation between storage media. For example, transmission mediaincludes coaxial cables, copper wire and fiber optics, including thewires that comprise bus 502. Transmission media can also take the formof acoustic or light waves, such as those generated during radio-waveand infra-red data communications.

Various forms of media may be involved in carrying one or more sequencesof one or more instructions to processor 504 for execution. For example,the instructions may initially be carried on a magnetic disk or solidstate drive of a remote computer. The remote computer can load theinstructions into its dynamic memory and send the instructions over atelephone line using a modem. A modem local to computer system 500 canreceive the data on the telephone line and use an infra-red transmitterto convert the data to an infra-red signal. An infra-red detector canreceive the data carried in the infra-red signal and appropriatecircuitry can place the data on bus 502. Bus 502 carries the data tomain memory 506, from which processor 504 retrieves and executes theinstructions. The instructions received by main memory 506 mayoptionally be stored on storage device 510 either before or afterexecution by processor 504.

Computer system 500 also includes a communication interface 518 coupledto bus 502. Communication interface 518 provides a two-way datacommunication coupling to a network link 520 that is connected to alocal network 522. For example, communication interface 518 may be anintegrated services digital network (ISDN) card, cable modem, satellitemodem, or a modem to provide a data communication connection to acorresponding type of telephone line. As another example, communicationinterface 518 may be a local area network (LAN) card to provide a datacommunication connection to a compatible LAN. Wireless links may also beimplemented. In any such implementation, communication interface 518sends and receives electrical, electromagnetic or optical signals thatcarry digital data streams representing various types of information.

Network link 520 typically provides data communication through one ormore networks to other data devices. For example, network link 520 mayprovide a connection through local network 522 to a host computer 524 orto data equipment operated by an Internet Service Provider (ISP) 526.ISP 526 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the“Internet” 528. Local network 522 and Internet 528 both use electrical,electromagnetic or optical signals that carry digital data streams. Thesignals through the various networks and the signals on network link 520and through communication interface 518, which carry the digital data toand from computer system 500, are example forms of transmission media.

Computer system 500 can send messages and receive data, includingprogram code, through the network(s), network link 520 and communicationinterface 518. In the Internet example, a server 530 might transmit arequested code for an application program through Internet 528, ISP 526,local network 522 and communication interface 518.

The received code may be executed by processor 504 as it is received,and/or stored in storage device 510, or other non-volatile storage forlater execution.

From the foregoing it will be appreciated that, although specificembodiments have been described herein for purposes of illustration,various modifications may be made without deviating from the spirit andscope of the present disclosure. For example, the methods and systemsfor performing cloning and synchronization discussed herein areapplicable to other architectures other than a Windows architecture.Also, the methods and systems discussed herein are applicable todiffering protocols, communication media (optical, wireless, cable,etc.) and devices (such as wireless handsets, electronic organizers,personal digital assistants, portable email machines, game machines,pagers, tablets, mobile devices, and navigation devices such as GPSreceivers, etc.).

The headers contained herein are for organizational purposes only andare not intended to limit the present disclosure in any way.

The invention claimed is:
 1. A method for synchronizing a desktop image across a plurality of endpoints connected to a server, comprising: cloning one or more layers of a centralized virtual desktop (CVD) data object located on the server to each of the plurality of endpoints, wherein not all the layers of the CVD data object are cloned to at least one endpoint, the CVD data object comprising a plurality of layers corresponding to the desktop image including a user files layer, a user applications layer, and a base image layer including an operating system; at a first endpoint, receiving an update to a target layer of the CVD cloned on the first endpoint; uploading the update from the first endpoint to the CVD on the server; and maintaining synchronization of the desktop image across the plurality of endpoints by downloading the updates from the CVD data object on the server to one or more of the remaining endpoints in the plurality of endpoints to which the target layer was cloned, and merging the update on the cloned target layer on each of the one or more of the remaining endpoints.
 2. The method of claim 1, wherein the updates are uploaded from the first endpoint in response to the first endpoint being designated a master device.
 3. The method of claim 1, wherein the first endpoint is designated the master device based on use of the endpoint by a user.
 4. The method of claim 1, wherein each of the remaining endpoints is blocked from making system-level changes locally.
 5. The method of claim 1, further comprising: downloading updates to the user files layer of the CVD data object to one or more of the remaining endpoints and merging the downloaded updates onto clones of the user files layers on the one or more of the remaining endpoints.
 6. The method of claim 1, further comprising: downloading updates to at least one of user profile and settings, application software, an operating system, and hardware dependent software layers of the CVD data object to one or more of the remaining endpoints and performing a lazy synchronization with corresponding clones of the at least one of user profile and settings, application software, an operating system, and hardware dependent software layers on the one or more of the remaining endpoints.
 7. The method of claim 6, wherein the lazy synchronization comprises downloading the updates to a staging area of the one or more of the remaining endpoints.
 8. A computing device for synchronizing a desktop image across a plurality of endpoints connected to a server, comprising: at least one processor; and memory including instructions that, when executed by the at least one processor, cause the computing device to perform the steps of: cloning one or more layers of a centralized virtual desktop (CVD) data object located on the server to each of the plurality of endpoints, wherein not all the layers of the CVD data object are cloned to at least one endpoint, the CVD data object comprising a plurality of layers corresponding to the desktop image including a user files layer, a user applications layer, and a base image layer including an operating system; at a first endpoint, receiving an update to a target layer of the CVD cloned on the first endpoint; uploading the update from the first endpoint to the CVD on the server; and maintaining synchronization of the desktop image across the plurality of endpoints by downloading the updates from the CVD data object on the server to one or more of the remaining endpoints in the plurality of endpoints to which the target layer was cloned, and merging the update on the cloned target layer on each of the one or more of the remaining endpoints.
 9. The computing device of claim 8, wherein the updates are uploaded from the first endpoint as a result of the first endpoint being designated a master device.
 10. The computing device of claim 8, wherein the first endpoint is designated the master device based on use of the endpoint by a user.
 11. The computing device of claim 8, wherein each of the remaining endpoints is blocked from making system-level changes locally.
 12. The computing device of claim 8, wherein the memory further includes instructions that when executed by the at least one processor, cause the computing device to perform the steps of: downloading updates to the user files layer of the CVD data object to one or more of the remaining endpoints and merging the downloaded updates onto clones of the user files layers on the one or more of the remaining endpoints.
 13. The computing device of claim 8, wherein the memory further includes instructions that when executed by the at least one processor, cause the computing device to perform the steps of: downloading updates to at least one of user profile and settings, application software, an operating system, and hardware dependent software layers of the CVD data object to one or more of the remaining endpoints and performing a lazy synchronization with corresponding clones of the at least one of user profile and settings, application software, an operating system, and hardware dependent software layers on the one or more of the remaining endpoints.
 14. The method of claim 13, wherein the lazy synchronization comprises downloading the updates to a staging area of the one or more of the remaining endpoints.
 15. A non-transitory computer readable storage medium for synchronizing a desktop image across a plurality of endpoints connected to a server, comprising one or more sequences of instructions, the instructions when executed by one or more processors causing the one or more processors to execute the operations of: cloning one or more layers of a centralized virtual desktop (CVD) data object located on the server to each of the plurality of endpoints, wherein not all the layers of the CVD data object are cloned to at least one endpoint, the CVD data object comprising a plurality of layers corresponding to the desktop image including a user files layer, a user applications layer, and a base image layer including an operating system; at a first endpoint, receiving an update to a target layer of the CVD cloned on the first endpoint; uploading the update from the first endpoint to the CVD on the server; and maintaining synchronization of the desktop image across the plurality of endpoints by downloading the updates from the CVD data object on the server to one or more of the remaining endpoints in the plurality of endpoints to which the target layer was cloned, and merging the update on the cloned target layer on each of the one or more of the remaining endpoints.
 16. The non-transitory computer readable storage medium of claim 15, wherein the updates are uploaded from the first endpoint as a result of the first endpoint being designated a master device.
 17. The non-transitory computer readable storage medium of claim 15, wherein the first endpoint is designated the master device based on use of the endpoint by a user.
 18. The non-transitory computer readable storage medium of claim 15, further comprising instructions that when executed by the one or more processors cause the one or more processors to execute the operations of: downloading updates to the user files layer of the CVD data object to one or more of the remaining endpoints and merging the downloaded updates onto clones of the user files layers on the one or more of the remaining endpoints.
 19. The non-transitory computer readable storage medium of claim 15, further comprising instructions that when executed by the one or more processors cause the one or more processors to execute the operations of: downloading updates to at least one of user profile and settings, application software, an operating system, and hardware dependent software layers of the CVD data object to one or more of the remaining endpoints and performing a lazy synchronization with corresponding clones of the at least one of user profile and settings, application software, an operating system, and hardware dependent software layers on the one or more of the remaining endpoints.
 20. The non-transitory computer readable storage medium of claim 19, wherein the lazy synchronization comprises downloading the updates to a staging area of the one or more of the remaining endpoints. 